Historically, computer users (whether individuals or enterprises) have purchased software and installed it upon their computers for execution. This “on-premises” software often required ongoing maintenance fees and upgrades, as well as outright replacement. In the 1990s, though, the expansion of the Internet, greater broadband Internet access, and other factors led to software that is centrally hosted rather than being installed on customer's own machines.
This “on-demand software” or “software as a service” (SaaS) executes on a server computer remote from a client, and is accessed over the Internet by a client computer in order to receive the service that the software provides. The software may be third-party independent software from any of a variety of vendors, or may be software developed and managed by the SaaS vendor. Such software is popular because typically only an Internet browser is required on the client computer (or perhaps thin client software), any data is stored on the remote computer server, and software lifecycle costs are less than traditional on-premises software. Typical SaaS business applications include customer relationship management, human resource management, invoicing, accounting, databases, etc.
Because there may be numerous end users within a particular enterprise needing to access the SaaS Web site, each end user needing to be authenticated, proper authentication of each user and the associated Web traffic can be a problem. Or, an entity that supplies software-as-a-service over an Internet connection may need to verify that an individual end user who is attempting to use the service is actually a valid end user who has paid for the service. One prior art technique uses source IP-based authentication. With a traditional on-premise software product this technique may be effective within a typical user network, but a SaaS service is quite different because it is centrally hosted. Using this technique, the Internet gateway will not add the user's original IP address to any Web request of the SaaS service. Thus, the SaaS site will not be able to see the end user's internal IP address and cannot properly perform authentication.
Another prior art technique uses cookie-based authentication. Currently, many SaaS sites rely upon browser cookies in order to perform user authentication. But, there are a variety of scenarios in which this approach will not work. For example, this technique will not work in a non-browser application, cross-origin resource-sharing (CORS) request because the client application will not send cookies for such cases. Additionally, it is a big challenge to authenticate the HTTPS traffic if “man-in-the-middle” decryption is disabled. If disabled, any CONNECT request will not send a cookie, and the request cannot decrypt the traffic in order to inspect the cookie in an HTTPS payload.
In addition to software as a service, other Web sites that allow end users to connect and who must be authenticated may have difficulty in authenticating these users. Furthermore, requiring each end user to remember a user identifier and password, and to use them each time a session is initiated, can be burdensome. Moreover, loss of a computer or mobile device with a user identifier and password may lead to fraud if the device falls into the wrong hands.
For these and other reasons, a new technique and system are desired that provide accurate authentication of end users in conjunction with a SaaS Web site and with other Web sites that require authentication.